The present invention relates in general to the field of web portals, and in particular to a portal environment and a method for operating a portal environment. Still more particularly, the present invention relates to a data processing program and a computer program product for operating a portal environment.
Web Portals allow providing a role specific personalized view on applications and web contents of an enterprise by end users via a single entry point. Applications and information coming from multiple sources are aggregated into a portal page that serves a specific business need helping site visitors, customers or employees to get to their individual goals more efficiently. This could mean, for example, for an employee to get the individual job tasks done more quickly and do faster and better decisions because all relevant information and applications are immediately at hand on the corresponding portal page, or for a site visitor to find target information and application for her or his specific user profile. In those portal systems, the portal page is typically assembled by page editors putting the right set of application components, typically portlets, and the right set of accompanying web content onto those pages and then exposing those pages to individual user roles as needed. The web content in turn, is typically created by content authors using a web content management system that provides the means to efficiently create web content supporting concepts like workflow based approval processes for new content, previewing of new draft content, versioning, reusable design components to support consistent look and feel, targeting of the right content to the right user profiles, archiving and syndicating newly created or modified content from an authoring system to individual delivery systems.
On the other hand there is a trend in information technology (IT) towards social aspects of user interaction that are even more dynamic than what web portals provide today. So, new communities are created by end-users, permanently modified, and deleted again, representing dynamic teams, or interest groups. These communities share information for example via wikis, blogs, or files organized in folders that are created, modified and removed again depending on the current demand. Furthermore any such social artifact can be tagged and/or rated by anyone to make it easy for anybody to find it based on the individual interest or need. In summary portals are not sufficiently integrated with social backends or networks to be able to reflect the volatile character of today user interaction.
FIG. 1 and FIG. 2 show a conceptual prior art portal environment 1, and FIG. 3 shows a component interaction flow, in the prior art portal environment 1 to create a new portal page. In the portal environment 1 new portal artifacts can be add by instantiating page templates and/or portlets that are associated with specific applications or content. Furthermore the instantiation of portal artifacts can even trigger the creation of new portal web content as depicted in FIG. 3.
Referring to FIG. 1 and FIG. 2, a prior art portal environment 1 comprises a portal 10 used by a client 3 and connected to at least one backend 40 providing external web site data 42. To run at least one portal application the portal 10 comprises a page model component 12 comprising page models edited by an page editor 5, a portlet model component 14 comprising portlet models developed by a portlet developer 7, a templating component 15, a web content manager 16 used by content authors 8 and site designers 9 to create and update web content to be used, and a portal access control component 18. The page model component 12 and the portlet model component 14 are connected to a portal data base 20 storing different page models and portlet models. The web content manager 16 is connected to a web content database 30 and comprises a web content rendering engine capable of transforming a given content item into markup that can be rendered by the client 3.
Referring to FIGS. 1-3, in prior art, the integration of data from external web sites 42 of at least one external backend 40 is done using dedicated integration portlets of the portlet model component 14 that retrieve feed driven information, e.g. lists of social data like blog entries, list of shred bookmarks, etc., from a separate external web site 42, and generate according markup to be added as markup fragment to the overall page.
In this approach, a page editor 5 can add external capabilities to a portal page by putting a right integration portlet onto the page, such that the appropriate feed driven information gets added to the page. The corresponding conceptual component interaction flow between the client 3 and the web content manager 16 is depicted in FIG. 3.
Referring to FIG. 3, in a first step the client 3 creates a portal object, e.g. a page, from a template in the portal environment 1 by calling the corresponding model controller application programming interfaces (APIs) of the portal model component 12 or the portlet model component 14 that handle the page instantiation in the portal 10. The page model component 12 and/or the portlet model component 14 load a corresponding page template from the portal data base 20. The templating component 15 of the portal 10 listens for events triggered by the page creation process and retrieves mapped data of corresponding site areas. Further, the templating component 15 copies a corresponding site area from the web content manager 16 and sets a corresponding site area owner. Further, the templating component 15 maps the new side area data in the portal data base 20 and transmits the new page to the portal model component 12 or the portlet model component 14 portal application, which present the new page to a web browser of the client 3.
The fundamental problem with prior art solutions is the static nature of the integration. If a specific portlet displays the content of a given blog entry and this blog entry gets removed the portlet is broken and requires manual maintenance by either changing its configuration to get the content of a different blog entry or by removing the portlet.
Also new content is not easy to integrate. If there is a new interesting blog entry available on the backend a new portlet must be added to the portal and configured to get the content of the new blog entry.
This setup requires either interaction of an administrator with the rights to add, remove and configure portlets or to give corresponding access to the end users resulting either in even longer delays or a lack of security. Independent from that the prior art solution can also easily lead to an outdated and incomplete representation of the data to be integrated.